home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19950528-19950726
/
000146_news@columbia.edu_Thu Jun 15 10:56:14 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1995-07-31
|
5KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA23146
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Sun, 18 Jun 1995 06:40:23 -0400
Received: by apakabar.cc.columbia.edu id AA18283
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sun, 18 Jun 1995 06:40:21 -0400
Path: news.columbia.edu!spcuna!citicorp.com!uunet!usc!math.ohio-state.edu!uwm.edu!lll-winken.llnl.gov!osi-east2.es.net!oracle.pnl.gov!mica.inel.gov!pmafire!mars.poci.amis.com!cwis.isu.edu!news.cc.utah.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: set carrier on, server ##
Message-Id: <1995Jun15.165614.54075@cc.usu.edu>
Date: 15 Jun 95 16:56:14 MDT
References: <3rptu3$nhr@feenix.metronet.com>
Organization: Utah State University
Lines: 95
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <3rptu3$nhr@feenix.metronet.com>, brit@metronet.com (Brit Systems) writes:
> I am using MS-Kermit 3.14.
>
> I'm running through some scenarios with
> "set carrier on, server" and what happens when you loose the carrier.
>
> Here is what I get.
>
> 1) set carrier on, server, break connection, server exits
Yup. The way it ought to be.
> 2) set carrier on, server, start getting file, break connection,
> file transfer terminates, server waits forever
> (at least as long as I wanted to wait).
Correct. The current session terminated. Server mode was
perpetual.
> 3) set carrier on, server 120, start getting file, break connection,
> file transfer terminates, server waits until timeout then exits.
The very last part needs improvment but basically it's ok.
> 4) set carrier on, server 120, start getting very big file,
> file transfer completes, server exits since it it past timeout.
Yes, that's what the 120 says, be a server for that long.
> Specifically on scenario 2 and 3, is this just me?
>
> And on a related issue.
>
> 1) dial someone, set carrier on, start sending file, break connection,
> file transfer terminates.
Yup. Correct.
> 2) don't call anyone, set carrier on, start sending file,
> file transfer eventually times out.
Never a carrier then no CD drop state, and hence "no problem."
Head scratching goes here.
> It seems that only connect checks if CD before it starts.
> Send, receive, remote and server don't seem to check CD when they start.
> Is this right?
They don't. They have no idea of the state of the comms channel
so they work so long as bytes can be sent or they run out of retries.
See below for more on this part. Again, modems aren't the only way of
talking.
> So if I want to check CD myself, what's the best way.
> "wait 0 cd" seems to work but it prints and ugly "?Timeout message".
>
> \v(carrier) only says what you set carrier to.
>
> Is there a \v(cd)? I seem to have seen \CD written but don't know
> how to use it.
No, there isn't. Maybe there should be, but then modem comms
are only one of many comms channels. In addition, testing for CD involves
firing up the serial port and we may not want that to happen.
> Thanks again, for the many times ya'll have helped,
> Robbie Barton
----------
Let me be candid on this topic.
From the beginning of MS-DOS Kermit steps were taken to ensure the
program would not fail because some modem wire wasn't high or low. That
philosophy has carried (sic) forward to the present. Kermit is not dependent
on a modem being present and healthy. Near the release time of MSK v3.14 we
had a very reasonable request to drop connections when CD vanished, and I
added code to accomplish that task. We got there but just barely.
For CD dropping to be a failure one must first have CD asserted,
which explains your "don't call anyone" case. There's room to quibble here.
From your report we see that matters are slightly muddled regarding
what to do when CD drops. The principal reason for the muddle is CD is
a data link item and ought not penetrate into the higher level software
such as protocol stacks etc. There are many other communications pathways
which do not involve CD. In addition, the Kermit file transfer stack has
automatic retries on failures (from any cause, reasons for failures are
normally worthless: failed is failed) and they don't know about the comms
link troubles. So retries occur, and server mode is basically a loop with
retries (with CD off most of the time, of course), and so on.
What can we do about this? Not much right now. I'll have to do the
doing in the next release and try to add CD sensitivity where possible
without making a hash of the code. It won't be perfect in the sense that
CD dropping kills the program in a flash, as happens to programs totally
dependent on modems, but it will be better than at present. And we need
to explain a little more carefully what terminating a session means versus
exiting server mode completely.
Thanks,
Joe D.